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APOLLO EXPERIENCE REPORT 


GUIDANCE AND CONTROL SYSTEMS— 

ENGINEERING SIMULATION PROGRAM 

By David W. Gilbert 
Manned Spacecraft Center 

SUMMARY 


Engineering simulation in support of the Apollo Program guidance and control 
systems was used extensively for design analysis and verification, for certification of 
hardware operation under closed-loop conditions, and for verification of hardware/ 
software compatibility and of software and procedures on a mission -by -mission basis. 
The magnitude of the simulation effort was justified by the limited time and funds avail- 
able for developmental missions and the resultant necessity for success on each mis- 
sion. The simulators proved to be unexpectedly important in the development and 
verification of the onboard digital software. The magnitude of the task and the time re- 
quired to implement large hybrid -mission evaluation -type simulators were initially 
underestimated. The timely availability of subsystem hardware for evaluation in the 
simulators was an early problem. Later, formal mission-verification simulations 
were hampered because detailed mission plans, trajectories, and procedures were not 
available early enough to make a complete verification job possible. Experience indicates 
that the approach to minimizing unexpected program costs in constructing large, com- 
plex, final-verification simulators is to use highly competent, experienced personnel 
and to start planning early in great detail, but to delay implementation as long as pos- 
sible so the many changes and resimulations encountered as the program develops can 
be avoided. However, this approach must be balanced against the risk of not having the 
simulator operational at the optimum time. Finally, consideration should be given to 
having the large hardware -type simulator constructed and operated by the contractor at 
a Government facility. Thus, late in the program, when needed only occasionally, the 
simulator can be operated by civil service personnel so that a continuous contractor 
capability does not have to be maintained for a long period. 


INTRODUCTION 


Many types of activities are sometimes referred to as simulations. These activ- 
ities include environmental testing, crew training, and many types of digital computa- 
tion. The activity that is discussed in this report is characterized by the following 
basic features. The activity is primarily guidance and control (G&C) oriented; is 



performed in real time, usually under laboratory or room -ambient environmental con- 
ditions; uses general-purpose analog and digital computing equipment; and typically con- 
sists of a crew-station mockup and various amounts of subsystem hardware and special 
interface equipment. This activity is referred to as engineering simulation to differen- 
tiate this type from the other types of simulations conducted in the Apollo Program. 

The majority of the engineering simulation conducted at non-NASA facilities was 
performed by three contractors: one responsible for the command and service module 
(CSM) design and construction, one responsible for the lunar module (LM) design and 
construction, and one responsible for the design and programing of the primary guid- 
ance, navigation, and control system (PGNCS). The PGNCS was built by a group of 
subcontractors responsible to a NASA Manned Spacecraft Center (MSC) contractor; 
thus, all system hardware and software were Government -furnished equipment for the 
two module contractors. Some engineering simulation of a relatively minor nature was 
conducted at the PGNCS contractor facility in the latter part of the program. However, 
a somewhat larger portion of system simulation was conducted early in the program by 
a major command module (CM) stabilization and control system (SCS) subcontractor as 
part of the overall prime CM contractor effort. 

A similar situation did not exist on the LM system, because the prime contractor 
retained systems responsibility for the SCS, procured components from subcontractors, 
and provided simulation support at their facility. Another difference was the require- 
ment for the LM abort guidance system (AGS) for which no counterpart exists on the 
CM. The AGS provides attitude control and guidance to the rate stabilization and con- 
trol system developed by the prime LM contractor, who retained systems responsibility 
and provided simulation support for the AGS, which was built under a subcontract. An 
exception to this procedure occurred in that the MSC contracted separately with the 
same subcontractor for the software used with the AGS. In addition, MSC personnel 
provided supplementary in-house engineering simulation to support the subcontractor 
in the development and verification of AGS programs for mission use. 


BACKGROUND 


In early 1964, the Apollo Spacecraft Program Office arranged for a separate engi- 
neering subsystem manager, so that operational methods could be similar to those then 
being established for managing contractor activity in the development of the spacecraft 
hardware subsystems. These subsystem managers were responsible to the program 
manager for the technical direction and monitoring of contractor activities relative to 
a given subsystem. With the exceptions previously noted, the contractor engineering 
simulations were conducted primarily at the facilities of the prime contractors for the 
CM, LM, and PGNCS. The engineering simulations conducted at each of the contractor 
facilities and at the MSC are described in this report, followed by a discussion of the 
overall program, some problem areas, and recommendations for future programs. 
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SIMULATION AT COMMAND MODULE CONTRACTOR FACILITIES 


The major simulations conducted by the prime CM contractor and the relationship 
of the simulations to unmanned and manned missions are shown in figure 1. The type I 
studies were relatively simple analog sim- 
ulations of various mission phases; sim- 
plified cockpit and visual representations 
(or none at all) were used during this phase 
of activity, which lasted approximately 
18 months while two evaluator facilities 
were being built. These evaluators, 
wooden mockups of the CM with displays 
and controls connected to a hybrid comput- 
ing facility, were used during the next 
2 years for a series of detailed simulations 
of the various mission phases. Emphasis 
was placed on G&C systems evaluation and 
related crew procedures. During that 
early period, a series of docking simula- 
tions was conducted at one of the contrac- 
tor facilities where scene -generation 
equipment suitable for man-in-the-loop 
docking simulation was readily available. Figure 1.- Simulations conducted at prime 
Later, as the program developed, Block I CM contractor facilities, 

and Block II CM and subsystem configura- 
tions were defined. Evaluator II was mod- 
ified and updated to represent the Block I CM, and a hardware -type guidance computer 
was installed, together with the associated displays, controls, and optics. This facility 
was used to train the flight crew in the G&C system procedures for the first manned 
Block I mission. Before then, two unmanned missions (spacecraft 009 and Oil) had 
been supported by simulations that involved most of the G&C system hardware. The 
SCS gyroscopes and the guidance platform were mounted on a flight -attitude table. Be- 
fore the first unmanned mission (spacecraft 009), a simulation was conducted wherein 
even the service module structure and service propulsion system (SPS) engine actuating 
system were suspended on a special air-cushion mount and included in the simulation to 
verify structural mode stability as well as stability in the presence of large thrust 
vector misalinements at ignition. 

Later, the hardware -type simulations were repeated using Block II G&C equip- 
ment to certify the systems for flight. These simulations were expanded to include a 
detailed verification of the digital autopilot (DAP) and compatibility with the G&C hard- 
ware, because the DAP was a new feature of the Block II system. Reruns of this and 
the previous Block II hardware simulations were required to update the results as the 
structural-bending-mode data for the CSM/LM docked configuration were better defined 
and the thrust vector control (TVC) mode compensation was changed in the SCS and in 
the DAP. 

Evaluator I was modified and updated to represent the Block II CM, and the simu- 
lation computer complex was reprogramed for compatibility with the Block II systems 
and the requirements of the lunar missions. A series of mission-verification 
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simulations was performed to verify the G&C software and procedures for each mission. 
This particular simulator was placed under configuration control, and a formal system 
of reporting and clearing any discrepancies was initiated for the simulations. 

The mode of operation for these simulations evolved into a two-complex arrange- 
ment. The formal mission-by-mission simulation was performed on the mission eval- 
uator, which is a large hybrid computer complex with a crew-station mockup, external 
scene -generation equipment, and a hardware guidance computer. In addition, the sys- 
tems hardware in the G&C laboratory was interfaced with a relatively small amount of 
analog equipment and with the Evaluator II mockup to form a hardware evaluator com- 
plex. This entire complex was used separately to develop and verify changes to the 
G&C hardware, evaluate structural-mode stability and compensation, and verify proce- 
dures for malfunction detection. This mode of operation was maintained almost contin- 
uously until after the first lunar-landing mission, when the computer complex was 
reduced in such a manner that only the mission evaluator or the hardware evaluator 
could be operated at one time. 

SIMULATION AT LUNAR MODULE CONTRACTOR FACILITIES 


The major simulations conducted by the prime LM contractor and the relationship 
to the manned and unmanned missions are shown in figure 2. The prime LM contractor 
began work 1 year later than the prime CM 
contractor. During the first 18 months of 
the contract, the prime LM contractor sub- 
contracted a docking simulation task to one 
firm and an abort -from-powered-descent 
simulation task to another firm; the prime 
LM contractor existing facilities were used 
to perform hover-and-landing and rendez- 
vous simulations while two detailed LM 
simulators were being constructed. The 
first detailed simulator was in operation 
approximately 26 months after the LM con- 
tract was let. The hover, landing, and 
docking simulator, called the III-B, was an 
all-analog simulator that had a detailed 
wooden mockup of the LM crew station with 
functional displays and controls and an ex- 
ternal scene of the lunar terrain or of the 
CM. The m-B was used extensively for a Figure 2. - Simulations conducted at prime 
year to study the LM landing and docking LM contractor facilities, 

maneuvers. The descent, ascent, and 
abort maneuvers were studied on another 

simulator (II-B) that contained a similar crew-station mockup but used hybrid computa- 
tion; the II-B was scaled to accommodate the overall trajectory geometry rather than 
just the close-in mission phases simulated in the III-B. The III-B and II-B simulators 
were phased out in early 1966; the crew station from the II-B simulator was updated and 
used in the full mission engineering simulator (FMES). 
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The FMES is a large, hybrid simulator with a crew station, external visual 
scenes, and an interface with the flight control integration (FCI) laboratory, which con- 
tains all the G&C system hardware. The gyroscopes and the inertial measurement unit 
were mounted on a three-axis flight -attitude table, the gimbal -drive actuators of the de- 
scent engine were mounted in load rigs, and a hardware throttle -valve actuator was used.. 
Other subsystem hardware used included the control electronics, the LM guidance com- 
puter, and the AGS computer. In final operational form, the FMES required a complete 
tie-in to subsystem hardware. Provision was made for two modes of operation, the 
mathematical-model mode and the hardware mode, with quick changeover possible. 
However, maintaining an accurate mathematical model of the PGNCS software required 
a large, continuous effort as a result of software evolutions. Because of the doubt 
about the validity of the mathematical model (in the event of discrepancies) and for eco- 
nomical reasons, the mathematical-model mode of operation was not maintained. Be- 
cause the LM did not undergo an extensive modification program similar to the Block 1/ 
Block II CM configuration change, no simulator modifications of that sort were required. 

The FMES was used to support the certification testing of the G&C systems for the 
only unmanned LM mission. Because the first LM mission was unmanned, the G&C 
system contained some special equipment in the form of a program reader assembly to 
automate some of the manual functions and to supplement the untried primary system, 
which was included as hardware in the FMES simulations for certification purposes. 
These simulations were extended to provide a detailed verification of the PGNCS soft- 
ware program (SUNBURST 116); later, a reverification of SUNBURST 120 after revi- 
sions were made; and, still later, a specific verification of the DAP functions in these 
programs. The simulator was put under configuration control, and a formal system of 
reporting and clearing all discrepancies was initiated. This type of simulation was re- 
peated for each succeeding LM mission. 

Formal certification requirements existed until after the Apollo 11 mission, be- 
cause each mission involved a new requirement or a potential application of the system 
function. Significant software changes also were made after each mission. In fact, 
despite an additional LM simulator at the PGNCS contractor facility and the additional 
year or more of time available as a result of the spacecraft 012 accident, the degree of 
the prime LM contractor simulation support directly concerned with the LM software 
development and verification was far greater than anticipated or intended. This situa- 
tion reduced the time available for simulation verification of backup modes, of the AGS, 
and of malfunction-detection procedures. To alleviate this situation, the simulation 
operation at the prime LM contractor facility was put on a three -shift basis and the 
facilities at MSC were operated by subcontractor personnel to supplement the AGS sim- 
ulation and evaluation. This situation continued through May 1969, when the simulation 
returned to a normal one -shift operation. 


SIMULATION AT PGNCS CONTRACTOR FACILITIES 


The design of the PGNCS and associated software was the specific concern of the ' 
PGNCS contractor. The type of real-time simulation germane to this report was con- 
ducted early in the program for evaluation of certain crew tasks and of system compo- 
nents in closed-loop operation. A combined CSM or LM hybrid facility with functional 
crew stations was implemented later to aid in the development of the software and, 
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especially, of the crew procedures software interface. However, the primary software 
development tool was the non-real -time digital program. 

The first unmanned Block I missions were relatively simple, and the simulations 
were more concerned with the hardware operation. With the approach of the first 
manned (spacecraft 012) mission, the magnitude of the crew display and control inter- 
face with the software first became evident on the PGNCS and prime CM contractors 
simulators. Many unexpected discrepancies arose, requiring changes or alternative 
procedures. At approximately the same time, it became apparent that the problem 
would probably be greater for the Block II systems because the autopilot functions had 
been added to the PGNCS with no additional provisions for crew display or control; that 
is, all crew interface with the computer was only through the display and keyboard. As 
a result of the increasing software workload, the PGNCS contractor added a second 
hybrid simulator facility during 1967 so that the CSM and LM simulations could be con- 
ducted independently. These simulators served as developmental tools for portions of 
the software and as verification facilities for the assembled program. Each simulator 
contained a hardware guidance computer, a simulated inertial measurement unit, a 
crew-station mockup, special interface equipment, and general-purpose hybrid com- 
puting equipment for simulating the other spacecraft systems, equations of motion, and 
so forth. One PGNCS contractor innovation was the use of closed-circuit television 
and a video tape recorder so that procedural and software discrepancies could be re- 
played and separated. 

Software discrepancies reported by NASA and contractor organizations usually 
were re-created and checked on one of the PGNCS contractor simulators before a 
change was effected. This procedure tended to eliminate "false alarms" that were the 
result of simulator problems rather than actual system discrepancies. 


SIMULATION AT MSC FACILITIES 


The overall simulation activities con- 
ducted at the MSC are shown in figure 3 . 
Other simulations of the same types that 
were conducted by the MSC but not shown 
in figure 3 were primarily those performed 
on the procedures-development simulators 
and trainers. 

The simulations were begun in 
August 1962 in temporary quarters while 
the MSC was being constructed. During 
this period, which lasted almost 2 years, 
a series of analog man-in-the-loop sim- 
ulations was performed to evaluate basic 
vehicle -control concepts and handling qual- 
ities for the various mission phases. Dur- 
ing the first half of 1964, the simulation 
facility was moved to permanent quarters. 
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The following 3 years were characterized by an almost continuous series of simulations 
responsive to the program needs for definition of detailed G&C system requirements 
for all mission phases in both nominal and off-nominal conditions. 

The TVC simulations first established the feasibility of using a direct-manual- 
control mode as a backup. Later, heating problems with the SPS engine gimbal-drive 
actuators required lowering the maximum rate capability. Extensive simulations of 
both automatic and manual TVC modes were conducted to identify the minimum allow- 
able actuator performance and to define the flight restrictions that were required for 
some of the early systems (which had the low-rate actuators without the compensating 
changes in the control electronics). 

The long series of rendezvous simulations was concerned initially with manual 
backup procedures for LM direct ascent, then with the effect of the circular flight plan 
concept, and finally, with the evaluation of a one-man CSM-active rescue of the LM. 
During this period, simulations of the Gemini IV and Gemini VI rendezvous maneuvers 
were conducted to obtain a check between simulated and actual performance. 

The lunar-landing simulations were concerned initially with establishing the 
control-mode definition for the final descent, the associated pilot displays and controls, 
and the expected velocity dispersion at touchdown. Later, simulations were concerned 
with the effect of various descent-guidance techniques on pilot visibility of the landing 
site and the effect on the final approach trajectory. Still later, simulations were per- 
formed to evaluate landing -point -redesignation capability as a function of fuel availabil- 
ity and crew procedures for using this capability. 

These simulations (primarily analog simulations involving a crew-station mockup 
and an out -the -window scene generator) were concerned with G&C aspects of both the 
LM and the CSM systems. During the latter part of 1966, a Block I guidance system 
was interfaced with a CSM simulator to enable the actual flight software to be exercised 
during simulated mission phases. As a result of the impending buildup in Block II soft- 
ware activity, the Block I interface was discontinued and modified to a Block II configu- 
ration during 1967. A similar buildup of an LM verification simulator also was initiated 
during the same period. The resultant Block II CSM and LM simulators were much 
more complex and more formally controlled and operated than previous configurations. 

The CSM simulator was used to provide a formal verification of the entry-monitor- 
system software and the backup ranging capability, to evaluate the initial Block II soft- 
ware, to provide a check for the contractor simulations, and to investigate various 
failure-recovery situations. The LM simulator was used initially as an evaluation fa- 
cility for the AGS to supplement the limited amount of formal verification that could be 
done at the prime LM contractor facility because of the heavy workload there in sup- 
porting the development of the primary system software. In this respect, the LM sim- 
ulator served the same function as the hybrid simulators at the PGNCS contractor 
facility in supporting the development of the primary system software. In the case of 
the AGS, the hybrid facility was provided at the MSC rather than at the responsible sub- 
contractor facility. A hardware abort electronics assembly was interfaced with the 
simulator, and the actual flight programs and procedures were checked in various abort 
situations. 
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Afterward, the LM simulator was used to develop alternative procedures for var- 
ious failure situations that could possibly develop during the LM mission and to evaluate 
the detailed procedures and performance associated with the use of the landing -point 
designator as actually mechanized in the flight software. This latter task requires a 
high-quality external scene generator to achieve the required accuracy while maintain- 
ing the desired realism. Another somewhat novel feature of the LM simulator was the 
interpretive simulation of the actual guidance computer. (No hardware guidance com- 
puter was available for this purpose.) This interpretive simulation provided certain 
operational conveniences not associated with the hardware approach but was always the 
first suspect component when software anomalies occurred. Conversely, the location 
of a problem was not always evident when anomalies occurred with a hardware guidance 
computer in the simulation. The first suspect component was usually the piece of test 
equipment called the program -analyzer console, which provided a complete erasable 
memory for test purposes and simulator operation. The console memory was loaded 
with a punched paper tape. The program-analyzer console was a rather temperamental 
piece of equipment that was affected by power surges, surrounding equipment, electro- 
magnetic interference, temperature, and diverse external influences. As a result, fre- 
quent interruptions that were necessary to test or reload the memory load were normal. 


DISCUSSION 


Cost 

The simulations described in this report cost approximately $51 million through 
the Apollo 11 mission, not including the cost of the MSC simulations or the MSC sup- 
port contractors. This cost is less than 1 percent of the total cost of the areas served; 
that is, the CSM, the LM, and the onboard G&C systems development. In view of the 
nature of the Apollo missions (high cost, limited number, and resultant emphasis on the 
success of each mission), this cost does not seem unreasonable. 

Howe ver, the fiscal profile of the two spacecraft contractors was quite different. 

In the case of the prime CM contractor, an overall budgetary cost for simulations was 
negotiated ion the basis of a sketchy program plan. The plan proved to be too ambitious 
for the cost and had to be trimmed severely after 2 years. In the case of the prime LM 
contractor, a more modest but appropriate and well-defined simulation program was 
agreed upon, but only a small fraction of the total cost was included in the program 
budget. Two years elapsed before the required cost was actually defined, and it is un- 
certain that the cost was ever formally negotiated as an identifiable contract line item. 
As a result, the LM simulation program started at a slower rate and at a lower level 
than the CM program. Although the LM simulations cost less than half of what the CM 
simulations cost, the total for the LM was 50 percent more than the first complete esti- 
mates, primarily because of lengthened program schedules and tasks added by the MSC. 
The added tasks were concerned primarily with additional verification support for the 
primary G&C software. The simulation costs for the CM were close to the original 
estimate, despite the fact that the program had been severely abbreviated in scope al- 
though lengthened in schedule. 
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Scheduling Problems 

As ideally envisioned early in the Apollo Program, the mission-verification sim- 
ulations were to have been completed approximately 4 months before launch so that the 
final 4 months of crew training could be performed using a set of detailed procedures 
and software that had been verified by engineering personnel for the particular mission. 
In practice, this ideal was never really possible, with the result that the more typical 
operational sequence was as follows. 

The mission simulations started approximately 4 months before launch because 
detailed mission definition, trajectory data, and flight software normally were not 
available sooner. Detailed simulations of each mission phase and related contingency 
situations were performed for approximately 2 months. Usually, some changes were 
made to the mission profile, the crew procedures, and, sometimes, to the flight soft- 
ware during this time. A series of final software -verification tests was conducted 
2 months before launch. These tests comprised a series of formally controlled and 
documented simulations using the latest available mission trajectory plan, crew proce- 
dures, and flight software. The simulations, which had to be completed within 2 weeks 
so that the detailed results could be published and distributed before launch, served as 
useful references during the actual mission. Then, the simulation activity for the next 
mission was begun; that is, approximately 6 weeks before one launch, simulator opera- 
tions for the subsequent mission had to be started to support the typical 2. 5 -month 
launch interval. Thus, any problems requiring simulation support during the 6 weeks 
before launch usually entailed the interruption of the preparations for the subsequent 
mission. The simulators at the MSC normally were scheduled to provide this type of 
close-in support. 

The amount of engineering simulation planned for each mission varied, depending 
on the complexity, the amount of new software, and the mission functions being per- 
formed for the first time, so that each mission simulation was actually treated as a 
special case. With respect to simulation support, 4-month launch intervals are almost 
ideal, provided that detailed mission definition and software are available and that sig- 
nificant differences exist in each mission or spacecraft system. Longer intervals tend 
to result in idle periods; whereas, 2.5 months is approximately the minimum launch 
interval that can be supported with results published before launch. The 2. 5 -month in- 
terval assumes that changes in the mission or spacecraft are minimal or that the cov- 
erage will not be complete. 

Almost without exception, every large hybrid simulator required much longer to 
get into operation than originally planned. Delays of 6 to 12 months were typical, even 
after allowing for unexpected changes. The basic problem appeared to be a general 
lack of experience on the part of the personnel involved, who, for the most part, pre- 
viously had not been concerned with such large and complex simulators, hi fact, few 
people had had such experience. This general lack of experience was a state-of-the-art 
condition in 1963; adequate equipment had only recently become available then and no 
one yet had widespread experience in the application of general-purpose computing 
equipment to large hybrid simulators with many hardware interfaces. As a result, the 
magnitude of the task was not understood fully. The troublesome areas included the 
total hybrid software -integration task and the incomplete understanding of many of the 
hardware interface details that affected the software. Sometime later, after the simu- 
lator was operating routinely, little doubt existed that the same group of people could 
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plan and execute a similar operation with much better scheduling accuracy and less 
trouble. However, the planned schedule would be longer from the start than the first 
one. The tendency to underestimate the task could occur on another program if the per- 
sonnel involved have not had direct experience in a similar operation. 


Mode of Operation 

The modes of operation for the two contractor simulation complexes had different 
results, as previously described. The basic reason was the amount of G&C system 
hardware that was made available to each contractor. The prime CM contractor was 
provided a complete PGNCS for the G&C laboratory and a partial system for the simu- 
lator. This contractor also had a similar complement of Block I hardware, some of 
which could be modified for use with the Block II system or used as peripheral equip- 
ment for data handling and up-link/down-link interface. When the basic G&C laboratory 
integration testing was completed, that system was used as a separate hardware- 
evaluator -type simulator for stability and control and for failure -mode evaluation. The 
partial system was used in the mission evaluator that had a large digital computer suit- 
able for long-term trajectory computation as required for mission simulations. Both 
the complete and partial systems had hardware guidance computers that required flight 
software programs. 

The prime LM contractor had only one PGNCS assigned to the FCI laboratory, yet 
had to support the simulator operation also. Another partial system was assigned tem- 
porarily for radar-integration testing, but this system was not available for simulation 
purposes. This dissymmetry was the result of a combination of factors, such as the 
precedent established by the prime CM contractor during the Block I portion of the pro- 
gram, the extremely tight delivery schedule requirements for each Block II system in 
support of spacecraft schedules, overall program budget problems, and the generally 
more critical and austere attitude of the LM project office. 

The prime CM contractor two-complex arrangement was more flexible and re- 
sponsive, which was appropriate because the CSM control systems had to contend with 
the docked LM and the resulting low-frequency bending modes as a basic mission TVC 
requirement. In the case of the LM, control of the docked CSM was a backup or contin- 
gency mode and did not warrant the same amount of attention. The large mission sim- 
ulators did not simulate much of the detailed fuel-slosh and bending dynamics, because 
these usually were studied separately in an all-analog simulation. At the prime LM 
contractor facility, this operation meant an interruption of the mission-verification 
simulations and attendant scheduling problems. Because the LM simulations usually 
were conducted using the subsystem hardware, flight -attitude table, and other interface 
equipment, a large amount of idle time would be expected. However, idle time for this 
reason was not a major problem. Some annoying equipment failures were experienced, 
but these rather infrequent failures usually were fixed quickly. The most troublesome 
piece of test equipment was the program -analyzer console that supplied the memory for 
the guidance computer. This component, which was used by all the simulators with 
hardware guidance computers, was a frequent source of lost time. Because the console 
was designed as a piece of laboratory test equipment, many functions other than the 
memory were provided. As proven by experience, a simpler piece of equipment that 
served only as a memory unit would have been better. 
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However, in all cases, large, expensive simulation facilities were built at the 
contractor facility. This practice is good early in the program because the appropriate 
contractor personnel are certain to become directly involved in the operation. How- 
ever, if an unusually long operational period is scheduled, as in the Apollo Program, 
maintaining the contractor capability can become expensive if the facility is required only 
during short, infrequent periods. Possibly, a more economical approach that should 
be given consideration would be to have the contractor personnel build and operate the 
simulator at some permanent Government facility. Later in the program, the simula- 
tor could be operated as required by civil service personnel. 


The Role of Simulation 

The intended role of the simulation activity in the overall program has a major 
effect on program implementation, cost, and mode of operation. Early in the program, 
the assumption was made that a mission simulation would be a flight constraint on each 
launch. Although experience showed that such was not the case, in the 2 years that 
elapsed before this concept was changed, a considerably more ambitious and expensive 
program was being prepared at the prime CM contractor facility to provide full 
simulation-support capability. To minimize the risk of delaying a launch because of 
simulator problems, two complete simulators were being built. The simulators were 
started early to make certain they would be ready, with the result that a continuous 
series of changes was needed to "track" the evolving spacecraft design. With the sched- 
ules that existed at the time, it was not apparent that one set of subsystem hardware 
could be made available for simulation before the first mission and providing two sets 
was out of the question. 

As experience showed, a limited number of simpler simulations were designated 
as certification test requirements for the subsystem hardware. These simulations were 
scheduled to be completed before the first mission on which the particular system or 
function was to be used. However, evidently, lack of completion of these tests for any 
reason other than trouble with the system being tested would not constrain the launch if 
all other testing were completed satisfactorily. The situation never actually arose be- 
cause all required simulations were completed in time; however, the redundant simula- 
tion approach was discontinued. 

Later in the program, a requirement for a formal software -verification simula- 
tion was added and scheduled to be completed before each launch. In most cases, these 
additional simulations also were completed in time, but some planned exceptions were 
made when it became evident that meeting all schedules would be impossible. 


CONCLUDING REMARKS 


On the basis of the Apollo experience, the following recommendations are made 
concerning engineering simulation for future large programs. 

1. Engineering simulation should be recognized as a potentially large, expensive 
operation and, as such, given appropriate attention during the initial contract definition 
and negotiations so that well-defined base-line plans and costs are established. 
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2. The role that simulation is expected to have in the program should be defined 
in enough specific detail so that an appropriate simulation plan that is adequate but not 
unnecessarily elaborate can be established. If possible, this should be included in the 
request for proposal so that the initial proposal by the contractor can be expected to 
contain appropriate plans and costs. 

3. Management of the simulation activity should be delegated in some appropriate 
way so that the activity will receive adequate full-time attention. 

4. Provision should be made so that any plan adopted can be supported adequately 
with the required subsystem hardware and test equipment. 

5. Consideration should be given to having large simulators that require subsys- 
tem hardware constructed at Government facilities. Contractor personnel would be 
used as required during construction and the initial phases of operation, and civil serv- 
ice personnel would be used later in the program. 

6. Detailed planning for large simulators should be begun early in the program, 
but actual implementation should be delayed as long as possible to avoid "tracking" and 
incorporating interim changes to the system being simulated. 

7. Detailed planning should be designed to ensure the inclusion of the require- 
ments for special-purpose equipment for interface or subsystem simulation, external 
scene generators, and the provisions for data input and output, because these require- 
ments can become expensive. 

8. At the beginning of the proposed program, the degree of desired formality 
associated with the simulator operation should be determined so that proper plans can 
be made. Configuration control, documentation, extra sets of hard-copy data, formal 
test -readiness reviews, and anomaly reporting can comprise a greatly increased work- 
load for support personnel. 


Manned Spacecraft Center 

National Aeronautics and Space Administration 
Houston, Texas, January 4, 1972 
914-50-17-08-72 
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